feat(desktop): import from Chrome, Edge, Brave, Vivaldi, Opera, Arc and Firefox - #7260

Firefox keeps its lock files inside each profile, not at the user-data root, so
the running check never found them and offered imports from a live, mid-write
database. It now walks the source's profiles and looks for all three names the
platforms use.

Firefox isolates cookies per container and per private window through
`originAttributes`. Electron has no equivalent, so importing them all collapsed
several identities onto one host/name/path and handed the profile whichever
container was written last. Only the default container is imported.

The sidecar copy no longer ignores every error alongside the missing-file case;
the new snapshot test caught that the earlier fix had landed on the
pre-extraction copy of this code rather than the shared module.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The Firefox branch failed with an anonymous `{ reason, cause }` literal, and
typing the shared `read` value as that shape erased `ChromiumCookieReadError`'s
tag from the error channel — neither branch could then be handled with
`Effect.catchTags`.

`FirefoxCookieReadError` mirrors its Chromium counterpart, so the union stays
structurally identifiable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Firefox keeps one cookie database per profile, so a failure carrying only a
reason cannot be traced back to the profile that produced it. The path is now a
structural attribute, matching `ChromiumCookieReadError`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Firefox has one failure mode — its plaintext database would not open — so a
single-value `reason` literal encoded the same thing as the tag, and `cause`
was optional though every construction site wraps a real failure. The error now
carries the database path and a required cause, and `BrowserImport` supplies
the user-facing reason where it maps the union.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The union was discriminated with a `cause._tag` ternary inside `Effect.mapError`
even though both members are statically known tagged errors; `Effect.catchTags`
says the same thing without the manual check. The comment above `read` claiming
both carry a `reason` was stale — Firefox's no longer does.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Firefox schema 16 (Firefox 129) moved `moz_cookies.expiry` from seconds to
milliseconds — the migration is `UPDATE moz_cookies SET expiry = expiry * 1000`
— but the reader passed the value straight through as seconds, so persistent
cookies from a current Firefox were imported ~1000× too far in the future.
Older profiles still hold seconds, so the unit is decided by `PRAGMA
user_version` rather than assumed either way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… browser

`isSourceRunning` treated `.parentlock` / `parent.lock` as proof Firefox held
the profile, but Firefox deliberately leaves those on disk after a clean exit
(as a last-used marker) and only releases the OS-level fcntl or handle lock —
so once Firefox had been used, the source reported `browserRunning` forever and
cookie import never proceeded.

Verified against Firefox's nsProfileLock.cpp: only the Linux `lock` symlink
(target `<ip>:[+]<pid>`) is unlinked on exit, so its presence plus a live pid
is the POSIX signal; a dead pid means a crash. Node has no fcntl probe, so
`.parentlock` carries no signal on POSIX. On Windows the held handle denies our
open as `Busy`, which is the signal there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…s detected

Follow-ups to the leftover-lock fix. On macOS a running Firefox writes nothing
but an empty `.parentlock` held with an fcntl lock — no symlink, no pid — so
reading only the Linux `lock` symlink missed it entirely and offered imports
from a live, mid-write database. Node exposes no fcntl, so a throwaway
`python3` child tries a non-blocking F_SETLK and reports whether it blocks;
any failure to get a clean answer counts as held, so a probe problem can
never unlock a live profile. The Linux symlink still short-circuits first.

The symlink's owner half is honoured too: a non-loopback address is a shared
profile locked from another machine, whose pid cannot be probed here, so it
stays held. Also drops a Safari paragraph from `entryExists`' doc that
described `databaseFileExists`' concern, not this helper's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… Windows lock probe

A Firefox import logged "Reading browser cookie key from the keychain" with the executable path even though it never touches a keychain, putting a false security-sensitive event in the audit trail; the log now sits behind the Chromium engine check. Also narrows isLockHeld to the Windows probe its doc describes (its only caller already guards on win32) and deletes entryExists, which that dead branch was the last use of.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ock symlink

The owner check treated only 127.0.0.1 and ::1 as ours, but Firefox writes
whatever its resolver returns for the machine's hostname — 127.0.1.1 on
Debian-style hosts, a LAN address elsewhere, loopback only when the lookup
fails. A crashed Firefox on such a host left a symlink the check read as
foreign and held forever, blocking import. The owner is now matched against
every address the machine answers to, via a new `HostProcessAddresses`
reference that mirrors `HostProcessHostname` and is injectable in tests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…name-resolved addresses as local

Two follow-ups on the Firefox lock detection.

A Dock-launched app has launchd's bare PATH, so `python3` could go unfound;
the probe now names `/usr/bin/python3` absolutely first. More importantly,
"held" is now only ever the script's own verdict: a probe that never ran —
no interpreter, or Apple's shim on a Mac without the developer tools, which
exits non-zero after prompting to install — is the probe being unavailable,
not evidence about the lock, and falls back to "not held" rather than
blocking Firefox import on that machine for good. The SQLite snapshot copes
with a live WAL as it does for every other engine.

And `HostProcessAddresses` collected only interface addresses, so a
hostname mapped in /etc/hosts to an address no interface carries — Debian's
127.0.1.1 — read as foreign, holding a crashed Firefox's lock forever. The
set now also includes what the resolver returns for the machine's hostname,
which is exactly what Firefox writes into the lock.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Firefox stores nsICookie::SAMESITE_UNSET (256) for a cookie that carried no
SameSite attribute, distinct from SAMESITE_NONE (0), an explicit opt-in to
cross-site use. The reader collapsed the unknown value onto Lax, and the
reviewed suggestion would have made it None — both change the cookie's
meaning. `ImportedCookie` now carries Electron's own `unspecified`, which lets
the target browser apply its default exactly as the source did, and both
engines map their "no attribute" sentinel (Firefox 256, Chromium -1) to it.

Also drops a doubled `/**` opener left above `cookieDatabaseCandidatePaths`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Rows from before schema 9 hold NULL in sameSite, which failed decoding
and aborted the whole import. Schemas 10-14 also keep the declared value
in rawSameSite beside a Lax default; apply Firefox's own schema-15
migration rule so an undeclared cookie imports as unspecified rather
than as an explicit Lax.

The hostname DNS lookup ran once per profile and even on Windows, where
the symlink lock that needs it never exists.